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Synchronous coordination systems allow the exchange of data by logically indivisible actions involv- 
ing all coordinated entities. This paper introduces behavioural automata, a logically synchronous 
coordination model based on the Reo coordination language, which focuses on relevant aspects for 
the concurrent evolution of these systems. We show how our automata model encodes the Reo and 
Linda coordination models and how it introduces an explicit predicate that captures the concurrent 
evolution, distinguishing local from global actions, and lifting the need of most synchronous models 
to involve all entities at each coordination step, paving the way to more scalable implementations. 



1 Introduction 

Synchronous constructs in languages such as Reo [ Q and Esterel Q are useful for programming reactive 
systems, though in general their realisations for coordinating distributed systems become problematic. 
For example, it is not clear how to efficiently implement the high degrees of synchronisation expressed 
by Reo in a distributed context. To remedy this situation, the GALS (globally asynchronous, locally 
synchronous) model [|9j [T33l has been adopted, whereby local computation is synchronous and commu- 
nication between different machines is asynchronous. 

Our work contributes to the field of coordination, in particular to the Reo coordination language, 
by incorporating the same ideas behind GALS in our approach to execute synchronisation models. 
More specifically, we introduce behavioural automata to model synchronous coordination, inspired in 
Reo (H. Each step taken by an automata corresponds to a round of "synchronous" actions performed 
by the coordination layer, where data flow atomically through a set of points of the coordinated system. 
The main motivation behind behavioural automata is to describe the synchronous semantics underlying 



Dreams 111811 . a prototype distributed framework briefly discussed in §5.2| that stands out by the decoupled 
execution of Reo-like coordination models in a concurrent setting. Dreams improves the performance 
and scalability of previous attempts to implement similar coordination models. Our automata model 
captures exactly the features implemented by Dreams. 

Behavioural automata assume certain properties over their labels, such as the existence of a compo- 
sition operator, and use a predicate associated to each of its states that is needed to guide the composition 
of automata. Different choices for the composition operator of labels and the predicates yield different 
coordination semantics. We instantiate our automata with the semantics for Reo and Linda coordination 
models, but other semantic models can also be captured by our automata [18]. We do not instantiate 
behavioural automata with Esterel as the propagation of synchrony in this language differs from our 
dataflow-driven approach Q. 

Summarising, the main contributions of this paper are: 

• a unified automata model that captures dataflow-oriented synchronous coordination models; 
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• the introduction of concurrency predicates, increasing the expressiveness of the model when deal- 
ing with composed automata; and 

• the decoupling of execution of a distributed implementation based on our automata model, by 
avoiding unnecessary synchronisation of actions whenever possible. 

Each behavioural automaton has a concurrenty predicate that indicates, for each state, which labels of 
other automata require synchronisation. When composing two automata, labels must be either composed 
in a pairwise fashion, or they can be performed independently when the concurrency predicate does not 
require synchronisation. We exploit how to use concurrency predicates to distinguish transitions of a 
composed automaton that originate from all intermediate automata, or from only a subset of them. We 
also illustrate how to obtain more complex notions of coordination by increasing the complexity of 
concurrency predicates. 

This paper is organised as follows. We introduce behavioural automata in §2 We then encode Reo 
as behavioural automata in[S3land Linda as behavioural automata in[S4l In[S5lwe motivate the need for 



concurrency predicates, both from a theoretical and practical perspectives. We conclude in §6 



2 A stepwise coordination model 

In this section we present an automata model, dubbed behavioural automata. This model represents our 
view of a dataflow-driven coordination system, following the categorisation of Arbab [3 ]. Each transition 
in an automaton represents the atomic execution of a number of actions by the coordination system. 
We describe the behaviour of a system by the composition of the behaviour of its sub-systems running 
concurrently, each with its own automaton. Furthermore, we allow the data values exchanged over the 
coordination layer to influence the choice of how components communicate with each other as well. We 
borrow ideas from the Tile model Ifl4l l4l. distinguishing evolution in time (execution of the coordination 
system) and evolution in space (composition of coordination systems). Behavioural automata can be 
built by composing more primitive behavioural automata, and each transition of an automaton denotes a 
round of the coordination process, where data flow atomically through zero or more ports of the system. 

We use behavioural automata to give semantics to Reo, based on the constraint automata model 15), 
and to (distributed) Linda lfl5l . Each label of an automaton describes which ports should have dataflow, 
and what data should be flowing in each port. We write P to denote a global set of ports, L[P] to denote 
the set of all labels over the ports PCP, and D to denote a global set of data values. We associate a 
predicate over labels to each state q of an automaton, referred to as G(q). These predicates are used to 
guide the composition of behavioural automata. 

Definition 1 (Behavioural automata) A behavioural automaton of a system over a set of ports P CP 
is a labelled transition system (Q,L[P],—>,Q), where L[P] is the set of labels over P, — > C Q x L[P] x Q 
is the transition relation, and C : Q — > 2 L I p l is a predicate over states and labels, called concurrency 
predicate, regarded as a function that maps states to sets of labels. 

The key ingredients of behavioural automata are atomic steps and concurrency predicates. Each label 
of a behavioural automaton has an associated atomic step, which captures aspects such as the ports that 
have flow and the data flowing through them, and concurrency predicate describe, for each state, which 
labels from other automata running concurrently require synchronisation. 



Example 1 (Alternating coordinator) We present the alternating coordinator (AC) in Figure 1 It re- 
ceives data from two data writers W\ and W% and sends data to a reader R. The components W\, W2 
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Figure 1: Alternating coordinator (left), and its behavioural automaton (right). 



and R are connected, respectively, to the ports a, b and c of the alternating coordinator. The alternat- 
ing coordinator describes how data can flow between the components, and coordination is specified by 



the behavioural automaton depicted on the right side of Figure 1 Each transition of this automaton 



represents a possible step in time of the coordinator AC, describing how the ports a, b, and c can have 
dataflow. Initially, the coordinator is in state qo, where the only possible action is reading a value wfrom 
W\ through a and sending it to the reader R through c, while reading and buffering a value v sent by W 2 
through b. Note that if only one of the writers can produce data, the step cannot be taken, and the system 
cannot evolve. In the next state, q\, the only possible step is to send the value v to the reader R, returning 
to state qo. The arrows between states represent the transition relation — K In both states there is the 
possibility of allowing the concurrent execution of other automata, provided that this execution does not 
interfere with the current behaviour. The conditions of when other automata can execute concurrently 
are captured by the concurrency predicate C, depicted by squiggly arrows fwv^J from each state. 



2.1 Labels, atomic steps and concurrent predicates 

Labels over a set of ports P are elements from a set L[P] with some properties required for composition, 
which we will introduce later. Furthermore, a label £ G L [P] can be restricted to a smaller set of ports 
P'CP, written^). We require each label £ G L[P] to have an associated description of where and which 
data flow in the connector, written as a(£), and captured by the notion of atomic step. 

Definition 2 (Atomic step) An atomic step over the alphabet P CP is a tuple (P, F, IP, OP, data) where: 
F CP IPGF OPCF IPr\OP = <d and data : {IPUOP) -> D. 

We write AS [P] to denote the set of all atomic steps over the ports in P.Pisa set of ports in the scope 
of the atomic step. The flow set F is the set of ports that synchronise, i.e., that have data flowing in the 
same atomic step. The sets IP and OP represent the input and output ports of the atomic step that have 
dataflow, and whose values are considered to be relevant when performing a step. Ports in F but not in 
IP or OP are ports with dataflow, but whose data values are not relevant, that is, they are used only for 
imposing synchronisation constraints. The data values that flow through the relevant ports are given by 
the data function data. We distinguish IP and OP to capture data dependencies. 

Concurrency predicates are used to compose behavioural automata. When composing two automata 
a\ and a%, if a\ has ports Pi, has the concurrency predicate Si, and is in state q\, then £j G Ci(^i) 
means that a 2 can perform £ 2 only when composed with a transition from a\, otherwise a 2 can perform 
I2 without requiring a\ to perform a transition^ When clear from context, we omit the restriction and 
write € 2 G instead of £ { 2 P[) G We give a possible definition for concurrency predicates based 

'We present a variation of the original definition of concurrency predicates 1 18 1 to make the decision of belonging to a 
concurrent predicate more local. 
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solely on the set of known portsj^] Given a connector with known ports Po, the concurrency predicate of 
every state is given by the predicate 

cp (P ) = {£ | a(£) = (P,F,IP,OP,data) ,P DF / 0} . (1) 



Example 2 We define the atomic steps and concurrency predicates from \Example I as follows 



a(s[(v,w)) = (P,abc,ab,c,{a,b,c i-)- w,v,w}) C(qi(v)) = cp(P) 

a{s 2 {v)) = (P, c, 0,c,{c^v}) e(q Q ) = cp(P) 

For simplicity, we write a\...a n instead of{a\,.. .,a„} when the intended notion of set is clear from 
the context. The alphabet P is {a,b,c}, and the concurrency predicates allow only steps where none of 
the known ports has flow. 

2.2 Composition of behavioural automata 

To compose behavioural automata we require labels to be elements of a partial monoid (L, ®), that is, (1) 
there must be a commutative operator (g> : L 2 — L for labels, and (2) the composition of two labels can be 
undefined, meaning that they are incompatible. For technical convenience, we require ® to be associative 
and to have an identity element. The atomic step (P,F,IP,OP,data) of a composed label £\ ®£ 2 must 
obey the following conditions, where, for every label £\ or £ 2 , a{li) = (Pi,Fi,IPi, OPi,datai}. 
PC? 1 UP 2 /PC (IP l UlP 2 )\(OPi U OP 2 ) datay ^ data 2 

F C F\ U F 2 OP C OP\ U OP 2 data = data x U data 2 

The atomic step of a label £ is represented by a(£). The notation m\ ^ m 2 represents that the values 
of the common domain of mappings mi and m 2 match. The requirements on the sets IP and OP reflect 
that when composing two atomic steps, the input ports that have an associated output port are no longer 
treated as input ports (since the dependencies have been met), and the output ports are combined. The 
intuition behind the removal of input ports that match an output port is the preservation of the semantics 
of Reo: multiple connections to an output port replicate data, but multiple connections to input data 
require the merging of data from a single source. 

We now describe the composition of behavioural automata based on the operator ® and on concur- 
rency predicates. This composition mimics the composition of existing Reo models l6l[TTl[8l. 

Definition 3 (Product of behavioural automata) The product of two behavioural automata b\ = (Q\, 
L[P\],— >i, Ci) and b 2 = (Q 2 , L[P 2 ],— > 2 , Q 2 ), denoted by b\ IX b 2 , is the behavioural automaton (<2i x 
Q 2 ,\-[Pi L)P 2 ],— >, C), where — > and C are defined as follows: 

-> = {((p,q),£,(p',q')) \p\p',q% 2 q',£ = £ 1 ®£ 2 ,£^±.}U (2) 
{{(p,q)A(p',q)) |p4,/,^^e 2 ( 9 )} U {((p,q),e,M)) k-W/ Pl) W/?)} (3) 
e(p,q) = 6i(p)ue 2 (9) for pEQ h qEQ 2 . (4) 

Case ([3]) covers the situation where one of the behavioural automata performs a step admitted by the 
concurrency predicate of the other, and case ([4]) defines the composition of two concurrency predicates. 



In practice, our framework based on behavioural automata, briefly described in §5.2 uses a symbolic 
representation for data values assuming that variables can be instantiated after selecting the transition. 
This suggests the use of a late-semantics for data-dependencies. Our approach to compose labels resem- 
bles Milner's synchronous product in SCCS ifTTl . with the main difference that the product of behavioural 
automata do not require the all labels to be synchronised. The product of labels from two behavioural 
automata can be undefined, and labels can avoid synchronisation when the concurrency predicate holds. 



2 Other semantic models may require more complex concurrency predicates. For example, the concurrency predicates for 
the Reo automata model 1 8 1 depend on the current state (Section 3.6.2 of 1 1 8 1). 
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where: 

a(j3(v)) = (act', a', a',®, {a' h-> v}) 
a(s4(v)) = (aa' ,a,®,a, {a h-» v}) 



Figure 2: Behavioural automaton of the lossy-FIFO connector. 




Figure 3: The sink and source ports of LF, AC, and their composition. 



cp(a,a') 




2.3 Example: lossy alternator 



Recall the behavioural automaton AC of the alternating coordinator, illustrated in Figure 1 Data is 



received always via ports a and b simultaneously, and sent via port c, alternating the values received 
from a and b. We now imagine the following scenario: the data on a becomes available always at a 
much faster rate than data on b. To adapt our alternating coordinator to this new scenario, we introduce 
a lossy-FIFO connector LF [1] and compose it with the alternating coordinator, yielding LF txi AC. 
Recall the definition of cp : P — > L[P] given by Equation (1) The behavioural automaton for the 



lossy-FIFO connector is depicted in Figure 2 and its atomic steps range over the ports {a, a'}, where 



a' is an input port and a is an output port. We depict the interface of both of these connectors on left 



hand side of Figure 3 After combining the behavioural automata of the two connectors, they become 
connected via their shared port a. The new variation of the alternating coordinator can then be connected 
to data producers and consumers by using the ports a', b and c, as depicted at the right hand side of 



Figure 3 



Intuitively, the lossy-FIFO connector receives data a' and buffers its value before sending it through a. 
When the buffer is full data received from a' replaces the content of the buffer. The connector 



resulting from the composition LF M AC is formalised in Table 1 and in Figure 4 The flow sets of the 
labels s\(v,w), S2{v), *3(v) and ^(v) are, respectively, abc, c, a', and a' a, and the set of known ports 
is P = {a' ,a,b,c}. Let Qlf and Qac be the concurrency predicates of LF and AC. The concurrency 
predicate Clfmac for LF M AC results from the union of the predicates of the states of each behavioural 
automaton, and corresponds precisely to the concurrency predicate that maps each state to cp(a' ,a,b,c). 
The name of each state in LF X AC is obtained by pairing names of a state from LF and a state from AC. 
Some states and transitions are coloured in grey with their labels omitted to avoid cluttering the diagram. 

From the diagram it is clear that some transitions originate only from the LF or the AC connector, 
while others result from the composition via the operator ®. The transitions and ^ (w) can be per- 
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Table 1 : Atomic steps of the composition of labels from LF and AC (left), and verification of the concur- 
rency predicate for each label (right). 
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Figure 4: Behavioural automaton for the composition of Li 7 and AC 



formed simultaneously or interleaved; simultaneously because 52 (v) (g>5 3 (w) is defined, and interleaved 
because Clf never contains 52 (v) and Qac never contains 53 (w). The possible execution scenarios of 
these atomic steps follow our intuition that steps 'approved' by concurrency predicates can be performed 
independently. The steps s\(u,v) and 54 (w) can be taken only when composed. 

2.4 Locality 

We introduce the notion of locality as a property of behavioural automata that guarantees the absence 
of certain labels in the concurrency predicates of independent behavioural automata, that is, in automata 
without shared ports. 

Definition 4 (Locality of behavioural automata) A behavioural automaton b = (Q, L[P], — y, C) obeys 
the locality property if, for any port set P' such that PHP* = 0, W G L[P']-Vq G Q-i^ G(q). 

Any two behavioural automata with disjoint port sets that obey the locality property can therefore 
evolve concurrently in an interleaved fashion. Let b = b\ tx ^2 be a behavioural automaton and t a label 

from b\. We say I is a local step of b if (qi,qi) — > (q'l^q^) * s a transition of b and either q\ — >\ g'j, 

<?2 = <?2' an d ^ ^ 62(^2); or q2 A2 g 2 > = 9i» an( ^ ^ G Si (91 ). In the behavioural automaton exemplified 



in Figure 4 the local steps are exactly the transitions labelled by the steps 52 (w) and 53 (v). 
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Proposition 1 Let b = b\t<\b2^xb-i be a behavioural automaton where bj = (Qi, L[P,],— >-,-, C,), for i G 
1..3, and assume the locality property from Definition 4 holds for b\, b 2 and b^. Suppose P\C]Pj, = 0. 
Then, for any step £^ G L[P\] performed by b\ and q2 G Qi, if&\ ^ 62(^2) then t\ is a local step of b. 

Proof. Observe that cxi is associative, up to the state names, because the composition of labels ® is 
associative. From Pi (IP3 = 0, i\ G \-[P\\, and from the locality property in Definition 4 we conclude that 



V<? G Q3 ■ 4 £ e 3 (<7). Therefore, for any state q 3 G Q3 and for a state q 2 G Q2 such that l y ( 1] £ 62(^2), 



(ft) 



we have that if 2 ' 



£ 62(^2) U 63(^3)- We conclude that 



*(ftUP 3 ) 



^ C, where S' is the concurrency predicate 



of b 2 cxi Z?3, hence a local step of ft. □ 
If the locality property holds for each behavioural automata b\ in a composed system b = b\ IX • • • XI 
Z?„, then, using Proposition 1 we can infer wether atomic steps from bj are local steps of b based only on 
the concurrency predicates of its neighbour automata, i.e., the automata that share ports with b\. 



2.5 Concrete behavioural automata 

A behavioural automaton is an abstraction of concrete coordination models that focuses on aspects rel- 
evant to the execution of the coordination model. As we will argue, Reo and Linda can be cast in our 
framework of behavioural automata. Therefore, both Reo and Linda coordination models can be seen as 
specific instances of the stepwise model described above. For a concrete coordination model to fit into 
the stepwise model, we need to define: (1) labels in the concrete model; (2) the encoding a of labels into 
atomic steps; (3) composition of labels; and (4) concurrency predicates. 

We start by encoding the constraint automata semantics of Reo as behavioural automata. Later, 
because of its relevance in the coordination community as one of the first coordination languages, we 
also encode Linda as a behavioural automaton. Other coordination models have also been encoded as 
behavioural automata in Proenga's Ph.D. thesis |fl~8l . 



3 Encoding Reo 

Reo U] 13 is presented as a channel-based coordination language wherein component connectors are 
compositionally built out of an open set of primitive connectors, also called primitives. Channels are 
primitives with two ends. Existing tools for Reo include an editor, an animation generator, model check- 
ers, editors of Reo-specific automata, QoS modelling and analysis tools, and a code generator ||5l[T6l. 

The behaviour of each primitive depends upon its current statej^] The semantics of a connector is 
described as a collection of possible steps for each state, and we call the change of state of the connector 
triggered by one of these steps a round. At each round some of the ends of a connector are synchronised, 
i.e., only certain combinations of synchronous dataflow through its ends are possible. Dataflow on a 
primitive's end occurs when a single datum is passed through that end. Within any round dataflow may 
occur on some number of ends. Communication with a primitive connector occurs through its ports, 
called ends. Primitives consume data through their source ends, and produce data through their sink 
ends. Connectors are formed by plugging the ends of primitives together in a one-to-one fashion to form 
nodes. A node is a logical place consisting of a sink end, a source end, or both a sink and a source endj^] 

We now give an informal description of some of the most commonly used Reo primitives. Note 
that, for all of these primitives, no dataflow is one of the behavioural possibilities. The Sync channel 



Note that most Reo primitives presented here have a single state. 
Generalised nodes with multiple sink and source ends can be defined by combining binary mergers and replicators Kil ll II . 
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( *) sends data synchronously from its source to its sink end. The LossySync channel ( >) 

differs from the Sync channel only because it can non-deterministically lose data received from its source 
port. The SyncDrain (> <) has two source ends, and requires both ends to have dataflow syn- 
chronously, or no dataflow is possible. The FIFOi channel ( — I I — ►) has two possible states: empty or 
full. When empty, it can receive a data item from its source end, changing its state to full. When full, 
it can only send the data item received previously, changing its state back to empty. Finally, a replicator 

( <X ) replicates data synchronously to all of its sink ends, while a merger ( — ► ) copies data 

atomically from exactly one of its sink ends to its source end. 
Example 3 The connector on the right is an exclusive router built by compos- 
ing two LossySync channels (b-e and d-g), one SyncDrain (c-f), one Merger 
(h-i-f), and three Replicators (a-b-c-d, e-j-h and g-i-k). The constraints of 
these primitives can be combined to give the following two behavioural possi- 
bilities (plus the no-flow-everywhere possibility): 

• ends {a,b,c,d,e,f,h,j} synchronise and a data item flows from a to j, 

• ends {a,b,c,d,f,g,i,k} synchronise and a data item flows from a to k. 

The merger makes a non-deterministic choice whenever both behaviours are possible. Data can never 
flow from a to both j and k, as this is excluded by the behavioural constraints of the Merger h-i-f. 

3.1 Constraint automata 

We briefly describe constraint automata [6]. Constraint automata use a finite set of port names N = 
{xi, . ■ ■ ,x n }, where x\ is the i-th port of a connector. When clear from the context, we write xyz instead 
of to enhance readability. We write jq to represent the variable that holds the data value flowing 

through the port Xj, and use N to denote the set of data variables {x\ ,x n }, for each x,- G N. We define 
DCx for each X C N to be a set of data constraints over the variables in X, where the underlying data 
domain is a finite set D. Data constraints in DCyj can be viewed as a symbolic representation of sets of 
data-assignments, and are generated by the following grammar: 

g :;= tt | x = d | giVg 2 | ->g 
where x G N and d G D. The other logical connectives can be encoded as usual. We use the notation 
a = b as a shorthand for the constraint (a = d\ Ab = d\) V. . .V (a = d n l\b = d n ), with D = {d\, . . .,d n }. 
Definition 5 (Constraint Automaton |6|) A constraint automaton (over the finite data domain DJ is a 
tuple A = (<2jN, —>,Qo), where Q is a set of states, N is a finite set of port names, — > is a subset of 
Q x 2"^ x DCy$ x Q, called the transition relation of A, and <2o Q Q is the set of initial states. 

X\g X\g 

We write q — > p instead of (q,X,g,p) G — ¥. For every transition q — > p, we require that g, the guard, 

0|tt 

is a DCx -constraint. For every state q G Q, there is a transition q > q. 

We define CAS C 2 N x DOm to be the set of solutions for all possible labels of the transitions of 
constraint automata. That is, X\g G CAS if X = \x\ ,x n \, g = /\x) = v,-, where v, G D, and there is a 

X\g' 

transition q > q' such that g satisfies g' . We call each s G CAS a constraint automaton step. Firing a 

X\g 

transition q — > p is interpreted as having dataflow at all the ports in X, while excluding flow at ports 
in N\X, when the automaton is in the state q. The data flowing through the ports X must satisfy the 



constraint g, and the automaton evolves to the state p. Figure 5 exemplifies the constraint automata for 



three Reo channels. We do not define here the composition of constraint automata, but encode labels of 



constraint automata as labels of behavioural automata, whose composition has been defined in §2.2 
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q O ab\tt flltt Q 9 D ab\a = b 



i a\a — d 



Figure 5: From left to right, constraint automata for the SyncDrain, Lossy Sync and FIFOi channels. 

I \ S2(w) Sl{w) 



„ (Sw)= ^(^tp^)^* 



<7,full(v) 



i2(w) <g>S4(v) 

Figure 6: Composition of [[Al]1 ca and [[l/IfI] ca , for any v,w G D. 
3.2 Constraint automata as behavioural automata 

The CA model assumes a finite data domain D, and that data constraints such as tt, a / d, or a = b stand 
for simpler data constraints that use a = d and the operators A and V. 

The encoding of the constraint automaton A = (Q, N, — >qa, 2o) is the behavioural automaton 

[A] CA = (e,L[^,^BA,e) 

with LpM], — s-ba, C, and the composition of labels defined as follows: 

• L = CAS, and a is defined as: a(X\/\? =l Xi = d t ) = 0,X, {*,• (->• <i,}" =1 ) . 

• We have g — >ba <?' for X|g G LpN] if g >ca q' and g satisfies g' . 

• Let ccw, = X{\gj be a solution for a label in a constraint automaton with ports K/, for / G 1..2. Then 

(x 1 ux 2 )|(giAg 2 ) ifx 1 n^ 2 = ^ 2 n^i Agi^g 2 

_L otherwise 
where gi ^g 2 if for any port xSli HX 2 and for any J G D, x = d satisfies g\ iff x = d satisfies g 2 . 

• Q(q) = cp(N) for every q G g. Recall that cp(N) = | a{t) = {P,F,IP, OP, data),P r\F ^ 0}. 
Example 4 Let A F = (Ql,^l,— >i,Qi) and Af = (Qf,^f,^2,Q2) be the constraint automata of the 



cas\ ®ca,S2 



LossySync and the FIFO\ channels, depicted in Figure 5\ The encoding of Al into behavioural automata 



is {Ql, LpsTJ,— >i, Qi), depicted in the left hand side of Figure 6 where: 
QL = {q], NL = {a,b}, Qi{q) = cp(N L )forqe Q L , s x (v) = ab\ (a = v Ab = v), s 2 (v) = a\(a = v), and 
-+L= {(q,si(v),q) | v G B>}U {(q,s 2 (v),q) \ v G D}. 

Similarly, the encoding of A F into behavioural automata is (Q F , LpMV ],— > F , Cf ). also depicted in 



Figure 6 where: 

Q F = {empty} U {full(v) | v G D}, Q F (q) = cp(N P ) for q G Q F , Ji F = {b,c}, s 3 (v) = b\(b = v), 
s 4 (v) =c\(c = v), and -^ F = { (empty, s 3 (v),full(v)) | v GD}L){(full(v),j 4 (v), empty) | v G D}. 

The composed automaton IAl} ca ixi [.Af]] c ^ is depicted in the right hand side of Figure 6 where 
s\ (v) (g)S3(v) = ab\(a = v Ab = v) and s 2 (>v) 0*4(v) = ac\(a = w Ac = v). 



The composed automata presented in Example 4| which differs from the lossy-FIFO, is equivalent to 



the product of the two associated constraint automata [6], with respect to the atomic steps of the labels 
of the automata. We expect this equivalence to hold in general, but we do not give a formal proof here. 
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4 Encoding Linda 

Linda, introduced by Gelernter [15], is seen by many as the first coordination language. We describe it 
using Linda-calculus |[T0ll , and show how it can be modelled using behavioural automata. Linda is based 
on the generative communication paradigm, which describes how different processes in a distributed 
environment exchange data. In Linda, data objects are referred to as tuples, and multiple processes can 
communicate using a shared tuple-space, where they can write or read tuples. 

Communication between processes and the tuple-space is done by actions executed by processes 
over the tuple-space. In general, these actions can occur only atomically, that is, the shared tuple-space 
can accept and execute an action from only one of the processes at a time. There are four possible 
actions, out(f), in(s), rd(s), and eval(f). The actions out(?) and in(s) write and take values to and from 
the shared tuple-space, respectively. The action rd(s) is similar to in(^), except that the tuple t is not 
removed from the tuple-space. Finally, eval(P) denotes the creation of a new process P that will run in 
parallel. We do not address e\al(P) here because it is regarded as a reconfiguration of the system. 



4.1 Linda- Calculus 

We use the Linda-Calculus model, described by Goubault Il2l . to give a formal description of Linda, 
studied also by Ciancarini et al. ifTOl and others. The Linda-Calculus abstracts away from the local 
behaviour of processes, and focuses on the communication primitives between a store and a set of pro- 
cesses. Processes P are generated by the following grammar. 

P::=Act.P | X \ recX.P \ P\\P | end (5) 
Act ::= out(f) | in(s) \ rd(s) (6) 

We denote the set of all Linda terms as Linda. The first case Act.P represents the execution of a Linda 
action. The productions X and recX.P are used to model recursive processes, where X ranges over a set 
of variables, and P\]P is used to model local non-deterministic choice. We assume that processes do not 
have free variables, i.e., every X is bound by a corresponding recX. Finally end represents termination. 

We model a Linda store as a multi-set of tuples from a global set Tuple. Each tuple consists of a 
sequence of parameters, which can be either a data value v from a domain D (an actual parameter), or a 
variable X (a formal parameter). We use the © operator to denote multi-set construction and multi-set 
union. For example, we write M = t ®t = and M@M = ^t,t,t,t\\, where t is a tuple and {\s,t\} 

denotes a multi-set with the elements s and t. 

A tuple-space term M is a multi-set of processes and tuples, generated by the grammar M ::= 
P | t | M ffi M. We adopt the approach of Goubault and provide a set of inference rules that give the 
operational semantics of Linda-Calculus. A relation match C Tuple x Tuple represents the matching of 
two tuples. (s,t) 6 match if t has only D values, and there is a substitution y whose domain is the set 
of free variables of s, such that t = s[y\. u[y] denotes the tuple or process u after replacing its free vari- 
ables according to y. We also write y = P/x to denote the substitution of x by the process P, and say t 
/-matches s when t matches s and ? = *[/]. 

Definition 6 (Semantics of Linda) The semantics of Linda is defined by the inference rules below. 
MeP[recX.P/X] — >M®P' M®out(t).P — >M®P®t (out) 

MerecX.P — >M@P' M (£>rd{s).P(Bt — > M ® P[y] ® t if t y-matches s (rd) 

M@P\\P' — >M®P (left) M®in(s).Pet — >M®P[y] if t y-matches s (in) 

MBPWP' -^M(BP' (right) M©end^M (end) 
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Example 5 The following sequence of transitions illustrates the sending of data between two processes. 
The labels on the arrows contain the names of the rules applied in each transition of Linda-Calculus. We 
use the notation P(x) as syntactic sugar to denote a process P where the variable x occurs freely. 

rd{A2,x).P{x) © out(42, 43).end © in(42,x) .P'(x) 
^>rd(42,x). J P(x)©end©in(42,x)./ y (x)© (42,43) rd(42,x).,P(x) ffiin(42,x). J P , (x) © (42,43) 
^> j P(43)ffiin(42,x). J P'(x)ffi (42,43) ^% P(43) 0^(43) 

4.2 Linda-calculus as behavioural automata 

We define an encoding function U L i nda : Linda — > BA, from Linda tuple-space terms to behavioural 
automata. Furthermore, we define the composition of atomic steps that preserve this semantics. We 
encode each Linda process P as a behavioural automaton, and we create a special behavioural automaton 
that describes the multi-set of available tuples. 

Let Act = {a\ae Act} and xAct = {% a | a G Act}. A port a is regarded as a dual port of a, and 
flow of data on a port T a represents the flow on the ports a and a simultaneously. The intuition is that 
the encoding of processes yields behavioural automata whose ports are actions in Act; the encoding 
of tuples yield behavioural automata whose ports are dual actions in Act; and the composition forces 
actions and dual actions to synchronise, i.e., to occur simultaneously. We define the global set of ports to 
be P = Act U Act U zAct, and define d = a. 

Let M = Pi • • • P n T be a tuple-space term. In turn, let T = t x • • • t m and m > 0. We define 
the encoding of M into a behavioural automaton as follows. 

M Linda = MLinda M Linda *" tt^Linda 

Hence, encoding M boils down to encoding Linda processes Pi and the Linda tuple-space T into different 
behavioural automaton. In both encodings of components and Linda tuple-spaces we define labels L as 
ports, that is, L = P = ActUActU xAct, and its encoding as atomic steps by the function a defined below. 



a (a) 



{a, ?act} , 0, 0, 0) if a G Act U Act, {act} = {a, a} DAct 
\ {a}, 0,0,0) if a GTAct 



The composition of two labels a\,ci2 G L is defined as follows. 

T act if «i ^ ?Act A a2 xAct A a\=di 
_L otherwise, 



where {act} = {01,02} HAct. The tuple-space is used to enforce every action a performed by a process 
to synchronise with the corresponding action a in the tuple-space encoded as a behavioural automaton. 
The definition of replaces every pair of ports with dataflow a and a by a new port with dataflow in z act . 
We encode a Linda process P as |P]]Li nda = (Qp, L, — >p, C), with components as defined below. 

• The set of states Qp is given by Qp = reach(P), where 

reach(put(t).P) = {out(t).P} Ureach(P) 

reach(rd(s).P) = {rd(t).P} U {{j{reach{P[y}) \ s y-matches t}) 

reach(in(s).P) = {in(t).P} U ({J {reach(P[y}) \ s y-matches tj) 

reach(P\\P') = {P[\P'}Llreach(P)l)reach(P') 

reach(end) = {end} 
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The transition relation — >p is given by the following conditions. 

out(f)-P' ^Kp 1 if t£ Tuple PtWPz-^Pi if Pi4P( 

rd(s).P' ^> P'[y] if sy-matchest P^-^P^ if P 2 A P* 2 

\xv{s).P ! P'[y] if sy-matchest 



• Q{q) = Act VJ Act for every state q. 

We now encode a Linda tuple-space T as [7l Linda = (Qj, L,— >t, C) with components as defined below. 

• Qt = 2 M( - Tuple \ where M(X) is a multi-set over the set X. 

• The transition relation — is given by the following conditions: 

M > M®tifte Tuple, t ©M f @M if s matches t, and t @ M ^-K M if s matches t . 

• C(g) = Act U Act for every state as in the encoding of Linda processes. 

Note that the input and output ports of the atomic steps obtained with a, introduced in §2.1 are 
always the empty set, that is, the data value flowing through the ports is not relevant, since the name of 
the port uniquely identifies the data. Alternative approaches to implement the encoding into behavioural 
automata that use the data values are also possible, but less transparent. 



Example 6 Recall the example presented in the end o f\§4.1 of a sequence of transitions of a tuple-space 



term in Linda-Calculus. We present below a simplified version of this example. 

rd(42,x). J P(x)©out(42,43)./ y ^% rd(42,x).P(x)©P'© (42,43) ^% P{42>) ®P'@ (42,43) 
The corresponding transitions in the encoded behavioural automaton are presented below. 

[rd(42,x).P(x)] Linda m [out(42,43).P'] Linda m [0j Linda 

[rd(42,x).P(x)] Linda m [P'l IX [(42,43)1 ^(43)] Linda x {P'j m [(42,43)1 

Observe that we assume an initial empty tuple-space, which is encoded as [[Oil Linda- A more careful 
analysis shows a one-to-one correspondence between the traces of the Linda-calculus term and the traces 
of the behavioural automaton, which we do not elaborate in this paper. 



5 Exploiting concurrency predicates 

We introduced a unified model for synchronous coordination that explicitly mentions concurrency pred- 
icates, which indicate which actions require synchronisation. We now exploit more complex definitions 
of concurrent predicates for Reo and Linda than in our previous examples, and briefly describe a practical 
application of behavioural automata in a distributed framework. 
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5.1 Complex concurrency predicates 

In our examples concurrency predicates of Reo hold when some shared ports from a composed automaton 
have dataflow ( Equation (1)| ), and concurrency predicates of Linda allow only a special set of actions zAct 



to run concurrently. We now present other concurrency predicates that capture notions such as context 
dependency and priority. 

Reo Other semantic models for Reo, such as connector colouring [11] and Reo automata O, capture 
the notion of context dependency, a feature missing in constraint automata. By modelling context depen- 
dency we avoid the undesired behaviour of the composed connector in Figure 6| where data is lost when 
the FIFOi buffer is empty, represented by the label sz{w). 

To avoid data from being lost, we replace the Lossy Sync channel by a context dependent LossySync 
channel, which is built based on the LossySync channel by replacing the label S2(w) by a label ^(w). 
This new label has the same atomic step, i.e., cc(s2(w)) = OC^iw)), but can be executed in parallel 
only if its neighbours require the port b to have no dataflow. This condition is enforced by adapting the 
definition of concurrency predicates to check wether a given set of ports Y requires synchronisation. 

cp ctx (P , Y) = {s K \s K ^ cp(P ) V X n Y / 0} (7) 

In our example, we avoid the losing of data by defining Q(q) = cp ctx (ab,%), C(empty) = cp ctx (bc,b), 
and C(full(v)) = cp ctx (ab,c). The label s\{w) is in C(empty) but not in C(full), i.e., s^iyv) can be 
performed independently of the FIFOi channel only when the FIFOi is full. Other important details, 
such as the composition of labels of the form , are not presented in this paper. A more precise and 
complete formulation can be found in Proenca's Ph.D. thesis (Sections 3.6.2 and 4.4.2 of |[T8l ). 



Linda Consider now that Linda processes have a total order <, representing a ranking among processes. 
When two processes can interact simultaneously with the shared tuple-space, only the higher rank should 
be chosen. We present only a sketch of this approach due to space limitation. 

We start by tagging labels I of the Linda behavioural automata with the process that executes it. 
For example, a label i of an automaton of a process p is renamed to t p . Labels of the shared tuple- 
space are not changed. The composition of labels must be such that l p ®~l = if. It is then enough 
to change the concurrency predicates of the automata of each process p in state q to Q(q) = Act U Act U 
\%\ | %i G xAct A x < p A q ^ end} and leave the concurrency predicate of the automaton of the shared 
tuple-space unchanged. Hence, a transition cannot be performed in parallel if it is in Act or Act, or if it is 
a X action from a process with lower priority and the current process is not yet stopped. 

5.2 Increased scalability via decoupled execution 

We use the behavioural automata model in a distributed framework, Dreams, where several independent 
threads run concurrently lTT8l . Each thread has its own behavioural automaton, and communicates only 
with those threads whose behavioural automata share ports with its own automata. The details regarding 
this tool are out of the scope this paper, but we explain how it benefits from using behavioural automata. 
The diagram in Figure 7| depicts the configuration of a system in Dreams, where each cloud represents 



an independent thread of execution, and edges represent communication links between threads whose 
automata share ports. The direction of each edge only illustrates the expected direction of dataflow. 
For efficiency reasons, and to allow a lightweight reconfiguration, Dreams does not create the complete 
behavioural automaton of a connector. Instead, it collects only the behaviour of the current round. 
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Knowing that only the labels of the automata relevant for the current round are composed, and as- 
suming that the locality property introduced in Definition 4 holds, we can perform local steps that, as 
the name suggests, involve only a subpart of the system. Recall the example of the lossy alternator, 
presented in §2.3 The diagram in Figure 7 uses the same example, in a context where two arbitrary large 
connectors connector^ and connector are attached to the source of the lossy alternator, and a reader 
component is attached to the sink of the lossy alternator. Consider that the reader can always receive any 
data value, that is, its behavioural automaton has a single state, and a transition labelled by r(y) for every 
data value v, such that a(r(v)) = (c,c,c,®,{c h-> v}). 

Observe that we do not use explicitly the composed connector LF x AC, but LF and AC as inde- 
pendent entities instead, since the Dreams framework can postpone the composition of their labels to 
runtime. Consider that the AC automaton is in state qi(v), hence it can perform a step ^(v), writing a 
value v to the port c. In this example AC is connected via the ports a, b, and c. The label s<i(y) does not 
have dataflow on a nor on b, and the reader can perform a label r(v) because ^(v) <8> r(v) ^ J_. Using 
the concurrency predicate in Equation (1) we conclude that *2(v) <8> r(y) is in the concurrency predicates 
of LF and connector. Furthermore, from the locality property we conclude that all other connectors not 
attached to AC also allow ^(v) <8> r(v) to be executed concurrently. Hence, Dreams can chose to perform 
this step by analysing only the behaviour of AC and reader, depicted by a grey box. 

The instantiations of Linda and Reo yield a similar result. The shared tuple-space can communicate 
with a single process at a time, without synchronising with every other process. Reo can, for example, 
send data from a full FIFOi independently of the behaviour of the connector attached to its sink port. 
The benchmarks performed for the Dreams framework [18] show optimistic results regarding the use of 
local steps in synchronous coordination. 



6 Conclusion 

We introduce behavioural automata to model coordination systems. The three main concepts that under- 
lie behavioural automata are atomicity, composability , and dataflow. We allow a sequence of actions that 
cannot be interleaved with interfering instructions (atomicity), we construct more complex systems out 
of building blocks that can be analysed independently (composability), and we represent the data values 
that are exchanged between components (dataflow). 

Behavioural automata unify existing dataflow-oriented models with synchronous constructs by leav- 
ing open the definitions of composition of labels and of concurrency predicates. The focus of behavioural 
automata is on concurrent systems, and on avoiding synchronisation of actions whenever it is unneces- 
sary. By capturing a multitude of coordination models, we allow any of these models to be included in 
implementations based on behavioural automata, such as the Dreams framework. 

As future work, we expect to formally show the correctness of the encodings of Reo and Linda. We 
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would also like to discover which properties can be shown for behavioural automata that are directly 
reflected on encoded models. A more practical track of our work involves the development of tools. 
Further development of Dreams to make it ready for use by a broader community is in our agenda. 
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